昨天我們在專案裡導入了 ktlint 這個用來檢查程式碼排版風格的套件，我們可以透過 Gradle 的兩個指令 lintKotlin 及 formatKotlin 來檢查（Lint）及重新排版（Format）專案的程式碼。不過，雖然這個套件可以減少我們手動檢查及修正程式碼排版的工作，但這個指令需要人工來執行，根據我們的經驗，只要是人工執行的指令就容易被忘記或忽略，長期下來這樣的機制就形同虛設。該怎麼辦？

別擔心！這就是 TeamCity 出場的時刻啦！我們只要在 TeamCity 運行 Build 的步驟裡安插一步執行 ktlint 程式碼排版風格檢查，只要沒有通過這個檢查，即便程式碼能通過編譯及測試，我們也視為建置失敗，這樣就能即早確保程式碼品質有持續受到監控。

新增檢查排版風格的 Build Step

先請登入 TeamCity Server，選擇 Shopping Cart 專案頁面，點選左上角 Edit project 進入專案設定。

選擇畫面中間 Build Configurations 表格裡 Build 最右邊的 Edit 進入編輯功能。

選擇左邊側邊欄的 Build Step，準備新增一個建置步驟。

在 Build Step 設定頁，點選 Add build step 新增一個建置步驟。

設定 Build Step 的第一次事，就是要選擇 Runner。Runner 您可以想像成是一個 Worker 的能力，TeamCity 支援非常多的 Runner，比方說 JVM 生態系常用的 ANT、Gradle、Maven、Kotlin Script，或是 .NET 生態系的 NuGet、NAnt、NUnit、OctopusDeploy 系列，或是 Node.js、Python、Rake 等也有，近期更受歡迎的應屬 Docker、Docker Compose 所有。就算這些 Runner 都不符您意，還有終極的 Command Line、Power Shell 可以用，非常彈性！

以我們的練習專案來說，因為 ktlint 已經整合成 Gradle Plugin，所以我們 Runner Type 直接選 Gradle 即可。隨後對應出來的 Step name 可以依自己的想法來設定，我們就先用「Check code style」吧！Gradle tasks 裡寫的就是要執行的 Task 指令，這邊填入 lintKotlin。其他功能我們暫時都用不到，全部留空按 Save 儲存即可。

用 TeamCity 執行程式碼風格檢查

我們先回到 IntelliJ IDEA，把程式碼如同昨天練習一樣搞亂排版後強制 Commit & Push，然後再回到 TeamCity 的 Shopping Cart 專案看結果，應該就會看到類似下圖這樣建置失敗的畫面。

點進 Build 詳細頁面就可以看到失敗原因就是沒有通過 ktlint 的排版風格檢查。

我們再回到 IntelliJ IDEA，用 Gradle 的 formatKotlin 指令修正所有不符合排版風格範例的程式碼後再重新 Commit & Push，看看這次 Build 是否能通過？

果然通過了！確認過這個檢查機制後，以後只要有程式碼推到 Repository，TeamCity 就會在 Build 的時候一併檢查程式碼風格，若沒有通過就會發出警告。就算今天有在人本機開發時忘了或漏了檢查，TeamCity 也能當最後一條防線，確保程式碼庫裡的品質。

小結

今天我們將昨天學會的程式碼排版風格檢查工具 ktlint 搬到 TeamCity 上，讓 TeamCity 可以做團隊的第三隻眼，隨時看顧好程式碼庫的品質。這樣的技巧也可以用在許多不同的面向，我們在接下來會以靜態程式碼檢查、產生 API 文件等情境，跟大家介紹更多應用，敬請期待！